One of the few newsletters I try to read on a regular basis is the one put out by the good folks at WServerNews.com. Their January 5 issue has an excellent article on security entitled “Blame the Software.” In part, it talks about the way blame for a security breach gets progressively shifted as an audit of the situation progresses:
- Bam–you’re hacked!!!
- Blame the software!!
- We also need to confiscate the server that software is running on!
- It looks like the admin is really the one we should blame–he went rogue.
- Wait–who hired this guy in the first place? What kind of controls did we have over him and why weren’t they applied consistently?
- I think we all failed here, it’s clearly a failure of our corporate culture. We need to do a full review of our security policies and processes for applying them.
- Let’s move on, what’s done is done. We just need to make sure it never happens again.
“Note the progression here from blaming tools (software and systems) to placing the blame on individuals (usually an administrator) to recognizing that inadequate businesses processes (security policies and controls) are the true culprit. Unfortunately as the blame gets shifted around its energy also dissipates, and while the end result is typically a tightening of security controls the issue of how those controls got weakened in the first place is usually not addressed.”
The article goes on to discuss how, frequently, exceptions get made to security policies for reasons of convenience in order to get a high-priority task completed, and how an IT administrator might respond to such requests in a manner that won’t result in termination of employment. That’s often not an easy conversation to have – but it’s an essential conversation to have if we really want to address the problem. I’d recommend reading the article in its entirety.